Conventionally, a vehicular electronic control unit, or ECU, has a function that outputs a software product number that represents an identity of software used in the ECU, in response to a certain request from an external scan tool that diagnoses and detects failure of the ECU.
For example, Japanese patent document 2003-256228 (also published as US patent document 2003/0163664) discloses that a microcomputer in an ECU responds to a certain command transmitted from an outside device by transmitting, to the outside device, software version information that represents a version of software executed in the microcomputer. The software version information in this disclosure may correspond to the above-mentioned software product number.
Further, the ECU having multiple microcomputers implemented therein is well-known as disclosed in Japanese patent document JP-A-2004-310221, for example.
The conventional ECU having multiple microcomputers stores, in each of the microcomputers, the software product number used in those microcomputers for the output in response to the inquiry from the scan tool. That is, the scan tool to ECU communication includes (1) an input that specifies one of the multiple microcomputers that outputs the software product number, and (2) an output, to the scan tool, of the software product number of the software used in the specified microcomputer.
In addition, there may be two patterns of communication between the scan tool and the microcomputers. That is, (a) each of the multiple microcomputers has communication with the scan tool, and (b) only a specific microcomputer has communication with the scan tool. In the pattern (a), all of the microcomputers specified in the request from the scan tool transmit, to the scan tool, respective software product numbers in response to the request, and, in the pattern (b), the specific microcomputer acquires the software product numbers from the respective microcomputers in response to the request from the scan tool, and then the acquired product numbers are transmitted from the specific microcomputer to the scan tool.
In the rule/regulation implemented by California Air Resources Board, vehicles after the model year of 2010 must have one and only one Calibration ID (CID: equivalent of the software product number described above) for each vehicle. That is, from the scan tool's view, the ECU can have only one CID, regardless of the number of the microcomputers included therein.
Therefore, in case there are multiple microcomputers in one ECU, one specific microcomputer must respond to the request from the scan tool.
Thus, the specific microcomputer must have all of the software product numbers used in respective microcomputers in the ECU.
However, the above configuration of the software product number storage scheme has a problem if the software in the microcomputer that is not in direct communication with the scan tool must be replaced/changed. That is, if two microcomputers A and B are implemented in one ECU, and only the microcomputer A is configured to have direct communication with the scan tool, the software product number stored in the microcomputer A must be updated in the course of software update only related to the microcomputer B. That is, even when the software in the microcomputer A is not updated/changed, the contents of the stored information regarding the software product numbers stored in the microcomputer A have to be updated/re-written.